fs: add io_uring open operation
#7321
Conversation
|
I ran a benchmark in commit d0dc6b2. settings$ uname -a
Linux mox692-ThinkPad-P51 6.8.0-59-generic 61-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 11 23:16:11 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
# On commit `d0dc6b2`,
# uring bench
$ RUSTFLAGS="--cfg tokio_unstable_uring" cargo bench open_many_files
# thread pool bench
$ cargo bench open_many_filesSingle-threaded runtime
Multi-threaded runtime
While performance improves in a current thread runtime, the results actually regress as the number of threads increases. Currently there is only one global ring in the runtime, so increasing threads may be causing lock contention. I'll look into whether I can reduce the lock contention. |
|
The main feedback I have here is that although it's ok to use |
|
Update: Sync with master and now the base branch is 7357. |
|
This is ready for review. |
Based on here, Also, I've added a tiny verification step in the CI in 2ec8482. |
Overview
This PR implement io_uring version
opensystem call.Since common file operations, like
fs::readandfs::write, useopenunder the hood, I think suppporting open sysacall first is a good starting point.Also, since this is the first operation we actually ship, I've added:
enable_uring)Implementation
OpenOptions, the implementation is chosen based on the presence of cfg flags.open()method, which uses io_uring or thread_pool.open()onUringOpenOptions, if the machine does not supportio_uring, it will fall back to using the standardOpenOptions.Much of the code in this PR is ported from the
tokio-uringcrate.Why do we need our own
UringOpenOptions?The standard library’s
OpenOptionsdoes not expose accessors for its internal flags. However, when usingio_uringto perform theopensystem call, it's necessary to access these internal flags. Since this is not possible with the standard implementation, we define our ownUringOpenOptionstype.This limitation is tracked in the std (rust-lang/rust#76801), but it has not yet been resolved.